I am not sure if this should go into PHP 8.2 or not.

I am not sure if this should go into PHP 8.2 or not.

Fixing the heap corruption should target PHP-8.2 (unless it would be too disruptive a change). Proper support for new MySQL datatypes should probably target master. As I understand it, this PR is supposed to return the data as string; if you could add a respective test case, that would clarify.

I don't know what's causing the heap corruption or how to fix it. This PR only adds support for the new data type hence why I targeted master. A test would be nice, but I think it can only be tested with a MySQL 9 server and our test suite doesn't offer that yet.

I don't know what's causing the heap corruption or how to fix it.

Me neither (might have something to do with mysql_nd's arena allocation).

A test would be nice, but I think it can only be tested with a MySQL 9 server and our test suite doesn't offer that yet.

Even if the test would be skipped in CI, it would nonetheless be useful for local developement, and (for me) to see what's going on (i.e. if a string is returned, what the format would look like).

Thanks for adding the test. So MySQL sends the data as 4-byte binary floats in little-endian format accross the wire (not in network byte order)? If so, users would need to unpack("g*", $data) – that's okay for me (assuming that's sufficiently portable).

I don't actually know what users would do with this in PHP. I assume they wouldn't usually do this and instead use VECTOR_TO_STRING and then json_decode. I guess they could unpack it too if they really want. The point is that it sends the data the same way as BLOB fields do.

I don't actually know what users would do with this in PHP. I assume they wouldn't usually do this and instead use VECTOR_TO_STRING and then json_decode.

It was just because @richloh wrote:

A php data variable that holds the results, preferrably an array of floats with an array length that matches the vector length.
The native mysql client also has this type of output (as of v9).

So giving back an array of doubles (aka. "full support") would be nice for best compatibility with libmysql-client, but I'm fine with having only "basic support", i.e. passing back a binary string, but it might be a good idea to document this in UPGRADING (and to mention unpack("g*") there). Considering that pdo_mysql would behave differently depending on mysqlnd vs. libmysql-client in this case, seems to be harder to document. Since you're doing most of the work of implementing and documenting, I think you should decide. :) But maybe we get further input from others; after all, there is no need to hurry; there are still supposedly more than 5 weeks to RC1.

Considering that pdo_mysql would behave differently depending on mysqlnd vs. libmysql-client in this case, seems to be harder to document.

I don't think they would. Correct me if I'm wrong but I thought libmysql would work the exact same way. And in terms of the MySQL client, it returns a hexadecimal formatted string by default. I think this is the full support.

The bug report started in phpMyAdmin, which I believe is the reason for the expectation. PMA can implement such helper functionality once PHP supports this data type. But PHP should stick as close as possible to what libmysql does.

Missing PDO support here

Missing PDO support here

Can you expand on that? What is missing in PDO?